-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-20981: [Flight][Integration] Generic gRPC Test Runner and Server #44115
base: main
Are you sure you want to change the base?
Conversation
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's a valid filename? xD
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah I originally had this as auth_basic_proto.go
just in case. Then I decided to take a look into the naming rules and was surprised to learn that Go only has requirements for the first character of a filename (source).
Name: "auth:basic_proto", | ||
Steps: []scenario.ScenarioStep{ | ||
{ | ||
Name: "unauthenticated_action", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah, I like this idea of separating out the subcases
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we included the stubs in arrow-go?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do, and I was originally using them first started prototyping. As a matter of principle though, I think that this module should avoid relying on any existing arrow implementations (arrow-go in this case) as it could introduce circular logic in tests and make that particular implementation authoritative instead of this suite.
If we only use the generated stubs from arrow-go, that's fine but from go.mod
's perspective the entirety of arrow-go is still a dependency. It ends up being the developer's responsibility to not accidentally use non-generated code. By rebuilding the stubs for this module, the arrow-go dependency is removed entirely making the constraint explicit.
Rationale for this change
What changes are included in this PR?
Are these changes tested?
Are there any user-facing changes?